2020-02-03

关键字：ToastManager、应用消息通知

Android 应用往往少不了要与用户交互的场景。

所谓与用户交互，就是指用户需要主动或者被动接受来自应用的消息、状态提示的场景。

这种消息、状态的展示形式往往多种多样。但常见的也是比较合适的是弹窗式交互。

弹窗式交互是在应用内展示的。即在应用运行过程中以1、Toast 式弹窗通知；2、对话框式弹窗通知；两种形式来与用户交互。

其中，第 1 种交互笔者称之为“弱交互式通知”，它弹出来以后过一段时间即会自行消隐。用户只需要看，完全不用去处理，甚至可以连看都不看。

而第 2 种笔者则称之为“强交互式通知”，它会弹出一个对话框，用户只能手动点击对话框上的相应按钮才能关掉对话框。

这两种交互弹窗的实现可就太容易了。第一个就是 Toast，而第二个则是 Dialog。堪称是小学生都能做出来。

但今天这篇博文，不聊实现方式。来聊聊在一款应用中应如何对待各种各样的弹窗式消息通知。

根据笔者的经验，在整个应用中统一管理弹窗式通知是最合理的。如何统一管理呢？

即严禁私自创建 Toast 或 Dialog 来展示，这样可能会导致同时弹出多个弹窗的情况从而引发通知混乱。

取而代之的是所有需要弹出的通知都交由同一个通知管理类来弹出。

有了这个统一的入口，我们就可以很方便地管控通知了。是即时弹出、是过滤、是排队弹出或是其它各种需求，都可以在这个统一的通知管理类中很方便的实现。

笔者今天就在这里记录一下自己撰写的这么一个通知管理类 ToastManager。当然，笔者的这个类仅仅是根据自己的实际需求来实现的，并没有做到绝对的完善与完美，在此记录的主要目的是为了给自己备一下忘。

笔者的这个 ToastManager 目前有三种弹窗：

1、弱交互式弹窗；

2、强交互式弹窗；

3、强交互式选择弹窗；

强交互式弹窗的变种版，对话框上具有“确定”与“否定”两个按钮，可以通过回调方法来通知创建者用户的选择结果。

笔者这个 ToastManager 在本质上就是简单地对 Toast 与 AlertDialog 作一下封装而已。甚至连排队机制都还没有实现，如果你有兴趣，可以尝试着自己去实现。

对了，还有一个很重要的。因为这个通知管理类理论上允许在任意位置调用。而 Toast 和 Dialog 是不允许在子线程中弹出的，但这种情况笔者仅仅是做了打印提示处理。正常来讲应该是将所有的通知弹出请求都转换成在主线程来弹的，但很遗憾，笔者没有去实现，实在是因为懒~

话不多说，以下是 ToastManager 的源码：